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(54) Managing calls over a data network 



(57) A method and system of managing calls over a 
data network (20) includes determining an available 
bandwidth of the data network (20). After a call request 
is received for establishing a call between at least two 
network terminals (14, 1 6, 30), one or more of a plurality 
of resource elements are selected in response to the 
call request based on the bandwidth of the data network 
(20). The resource elements, which can include codecs 
(coders/decoders), packet sizes (for carrying audio da- 
ta), and others, are used in the requested call between 



the at least two network terminals (14, 16, 30). Further, 
a plurality of communities (402, 404, 406) may be de- 
fined each including one or more terminals. One or more 
usage threshold values may be assigned to a link or 
links (430, 432) between communities (402, 404, 406), 
and a call request is processed based on the one or 
more usage threshold values. The processing includes 
at least one of determining whether to admit the call re- 
quest and selecting resource elements to be used dur- 
ing a call between terminals over the link (430, 432). 
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Description 
Background 

[0001] The invention relates to managing calls over a 
data network, such as an Internet Protocol (IP) network. 
[0002] Packet-based data networks are widely used 
to link various nodes : such as personal computers, serv- 
ers, gateways, and so forth. Packet-based data net- 
works include private networks, such as local area net- 
works (LANs) and wide area networks (WANs), and 
public networks, such as the Internet. The increased 
availability of such data networks has increased acces- 
sibility among nodes, whether the nodes are located in 
close proximity to each other (such as within an organ- 
ization) or at far distances from each other. Popular 
forms of communications across such data networks in- 
clude electronic mail, file transfer, web browsing, and 
other exchanges of digital data. 

[0003] With the increased capacity and reliability of 
data networks, voice communications over data net- 
works, including private and public networks, have be- 
come possible. Voice communications over packet- 
based data networks are unlike voice communications 
in a conventional public switched telephone network 
(PSTN), which provides users with dedicated, end-to- 
end circuit connections for the duration of each call. 
Communications over data networks, such as IP (Inter- 
net Protocol) networks, are performed using packets 
that are sent in bursts from a source to one or more des- 
tination nodes. Voice data sent over a data network has 
to share the network bandwidth with conventional non- 
voice data (e.g., electronic mail, file transfer, web ac- 
cess, and other traffic). One standard that has been im- 
plemented for communications of voice as well as other 
data is the H.323 recommendation from the Telecom- 
munication Sector of the International Telecommunica- 
tion Union (ITU-T), which describes terminals, equip- 
ment and services for multimedia communications over 
packet-based networks. 

[0004] I n an I P data network, each data packet is rout- 
ed to a node having destination IP address contained 
within the header of each packet. Data packets may be 
routed over separate network paths before arriving at 
the final destination for reassembly. Transmission 
speeds of the various packets may vary widely depend- 
ing on the usage of data networks over which the data 
packets are transferred. During peak usage of data net- 
works, delays added to the transfer of voice data pack- 
ets may cause poor performance of voice communica- 
tions. Voice data packets that are lost or delayed due to 
inadequate or unavailable capacity of data networks or 
resources of data networks may result in gaps, silence, 
and clipping of audio at the receiving end. 
[0005] A need thus exists for an improved method and 
system to manage the quality of voice calls or other au- 
dio communications over data networks. 



Summary 

[0006] In general, according to one embodiment, a 
method of managing calls over a data network includes 

s determining usage information of the data network. A 
call request is received for establishing a call between 
at least two network terminals. One or more of a plurality 
of resource elements are selected as candidates for use 
in the requested call in response to the call request 

10 based on usage information of the oetwrt. k. 

[0007] In general, according to another embodiment, 
a method of managing calls in a telephony system in- 
cludes defining a plurality of communities each including 
one or more communication endpoints and assigning 

is one or more usage threshold values to a link between 
communities. Further, a call request is processed based 
on the one or more usage threshold values. The 
processing includes determining whether to admit the 
call request over the link. 

20 [0008] Some embodiments of the invention may pro- 
vide one or more of the following advantages. Resource 
elements can be selected to optimize quality of service 
while at the same time taking into account the usage of 
the data network as well as usage of other transmission 

25 or communications resources. Proper selection of re- 
source elements as well as call admission control re- 
duces the likelihood of overburdening links between ter- 
minals. As a result, the likelihood of delays in the com- 
munication of audio data that may lead to various audio 

30 distortions is also reduced. By efficiently using packet- 
based data networks for telephony and other forms of 
audio communications, sharing of such data networks 
for carrying audio data (which are relatively time sensi- 
tive) and traditional forms of digital data (such as elec- 
ts tronic mail traffic, file transfer traffic, and other traffic) 
can be made more effective. 

[0009] Other features and advantages will become 
apparent from the following description and from the 
claims. . 

40 

Brief Description Of The Drawings 

[0010] Figs. 1 A-1B are block diagrams of an embod- 
iment of a telephony communications system in which 
45 voice or other audio data may be communicated over 
packet-based data networks. 

[0011] Fig. 2 illustrates the flow for processing a call 
request between an origination terminal and a destina- 
tion terminal in accordance with one embodiment. 
so [0012] Fig. 3 is a flow diagram of tasks performed by 
a call server in response to a call request in accordance 
with one embodiment. 

[0013] Fig. 4 illustrates the flow for processing a call 
request between an origination terminal and a destina- 
55 tion terminal in accordance with an alternative embodi- 
ment. 

[0014] Fig. 5 is a flow diagram of tasks performed by 
a call server in response to a call request in accordance 
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with the alternative embodiment. 

[0015] Fig. 6 illustrates components in a terminal and 

call server of Figs. 1 A-1 B. 

[0016] Figs. 7A-7B illustrate E-model charts that map 
conditions of a network linkto a desired quality of service 
in accordance with an embodiment. 
[001 7] Fig. 8 illustrates a flow for processing a call re- 
quest in accordance with an embodiment that utilizes 
the E-model charts of Figs. 7A-7B. 
[0018] Fig. 9 illustrates a telephony communications 
system that includes a plurality of communities and links 
between the communities over which call admission 
control is performed in accordance with an embodiment. 
[0019] Figs. 10A-1 OB illustrate the flow for managing 
a call request between terminals in different communi- 
ties of Fig. 9. 

Detailed Description 

[0020] In the following description, numerous details 
are set forth to provide an understanding of the present 
invention. However, it will be understood by those skilled 
in the art that the present invention may be practiced 
without these details and that numerous variations or 
modifications from the described embodiments may be 
possible. For example, although the description refers 
to telephony communications over data networks, cer- 
tain aspects of the methods and apparatus described 
may be advantageously used with other types of com- 
munications systems, such as those communicating 
video or multimedia data (for video conferencing, for ex- 
ample). 

[0021] Referring to Figs. 1 A and 1 B, one embodiment 
of a telephony communications system 10 includes a 
number of endpoints or terminals (terminals 14, 16, and 
30 illustrated) that are capable of performing voice or 
other audio communications over a packet-based or 
message-based data network 20. As used here, "teleph- 
ony communications 0 refers to the transmission and re- 
ceipt of sounds (e.g., voice or other audio signals) be- 
tween different points in a system using either wireline 
or wireless links. Example terminals 14, 16, and 30 may 
include computer systems with speech capability, tele- 
phone units that include interfaces to the data network 
20, gateways coupled to standard telephones 34 though 
a public switched telephone network (PSTN) 32, and 
other types of communication devices. Telephony com- 
munications can occur between any two or more termi- 
nals over the data network 20. 

[0022] The data network 20 may include, as exam- 
ples, private networks such as intranets (e.g., local area 
networks and wide area networks), and public networks 
such as the Internet. More generally, as used here, a 
data network is any communications network that utiliz- 
es message-based or packet-based communications. 
In one embodiment, the data network 20 communicates 
according to the Internet Protocol (IP), as described in 
Request for Comment (RFC) 791 , entitled "Internet Pro- 



tocol," dated September 1 981 . The data network 20 may 
include a single network or link or multiple networks or 
links that are coupled through gateways, routers, and 
the like. 

s [0023] In one embodiment, a call server 1 2 is coupled 
to the data network 20 to manage telephony communi- 
cations (e.g., call setup, processing, and termination) 
between or among the terminals 14, 16, and 30 (and 
other terminals). A policy server 18 may be accessible 

10 by the call server 12 to determine usage policy for te- 
lephony communications over the data network 20 to 
control the quality of service on the data network 20. For 
example, the policy server 18 may set the telephony us- 
age of the data network 20 for different time periods. 

15 During periods of expected high traffic (e.g., business 
hours), policy server 18 may set a low usage target for 
telephony communications. On the other hand, during 
periods of low expected traffic, the target usage of the 
data network 20 for telephony communications may be 

20 set higher. 

[0024] Additionally, a network monitor system 1 9 may 
be coupled to the data network 20 to monitor certain 
characteristics and conditions of one or more portions 
of the data network 20. The characteristics and condi- 

25 tions monitored may include packet delays, jitter, and 
packet losses. Packet delay refers to a delay experi- 
enced in transmission due to high traffic or other condi- 
tions. Packet loss refers to the percentage loss of pack- 
ets. Jitter refers to variations in the delay of different 

30 packets in the same transmission. Jitter may contribute 
to delay on a network link since receiving platforms need 
to buffer the received data packets to take into account 
the different delays of packets. 

[0025] Although only one call server and policy server 
35 are illustrated, multiple call servers and policy servers 
may be coupled to the data network. In this arrange- 
ment, each of the multiple call servers may be respon- 
sible for managing call requests from a predetermined 
group of terminals, and each policy server may be re- 
40 sponsible for maintaining usage policy for different por- 
tions of the data network 20. Further, more than one net- 
work monitor 1 9 may be included in the telephony com- 
munications system 10. For example, multiple network 
monitors may be located to enable monitoring of char- 
ts acteristics and conditions of different portions of the data 
network 20. A call server, policy server, and network 
monitor may be implemented on separate platforms or 
in the same platform. 

[0026] To establish a call between two or more termi- 
50 nals for performing telephony communications, a call re- 
quest is sent from an origination terminal to the call serv- 
er 12 for processing. The call request includes the IP 
address of the origination terminal, the directory number 
of the destination terminal, and a list of one or more re- 
55 source elements supported by the origination terminal 
to be used during an established calk A terminal may 
be relatively busy at the time a call is desired. As a result, 
processing capability and storage capability in the orig- 
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ination terminal may be limited so that resource ele- 
ments that require high bandwidth are not indicated as 
being supported. Examples of resource elements in- 
clude codecs (coders/decoders), the size of packets 
carrying audio data, and other resource elements, as 
explained further below. 

[0027] By querying the policy server 1 8, the call server 
1 2 determines the usage policy for the data network por- 
tions over which the call will be established and discards 
any resource elements that may be inconsistent with 
that policy. Additionally, the call server 12 can further 
restrict use of resource elements based on actual usage 
of transmission resources. Thus, for example, if a rela- 
tively large number of calls have been placed through 
the call server 12, the types of resource elements that 
may be employed for further calls may be those that 
have relatively low bandwidth requirements. Thus, the 
call server 12 is able to manage call requests based on 
usage information, including usage policy and/or actual 
usage of the data network 20. 

[0028] Optionally, according to some embodiments, 
the call server 12 may also query the network monitor 
19 to determine the current characteristics and condi- 
tions of the network. Selection of resource elements 
may thus further be based on the current characteristics 
and conditions of the network (e.g., delays being expe- 
rienced by packets and percentage of packet loss). 
Next, the call server 1 2 ranks the remaining supportable 
resource elements based on predetermined merit at- 
tributes, which may include quality of service, the avail- 
able bandwidth, expected usage of transmission re- 
sources, and other attributes. Selection of the resource 
elements to use for a particular call is based on the rank- 
ing performed by the call server 12. 
[0029] One type of resource element is the audio cod- 
er/decoder (codec) used by each of the terminals in- 
volved in a call session. An audio codec encodes audio 
signals originating from an audio input device (e.g., mi- 
crophone) lor transmission and decodes received audio 
data for output to an output device (e.g., a speaker). The 
codec can be implemented in software. Several types 
of codecs are available that have varying levels of data 
compression and data transfer rate requirements. For 
example, the G.711 codec provides uncompressed 
communications of voice data, but has a data transfer 
rate requirement of 64 kbps (kilobits per second) in each 
direction. Other codecs, such as the G.728, G.729A, G. 
729, G.723.1, and G.722 have varying compression al- 
gorithms and data transfer rate requirements (which are 
lower than that of the G.711 codec). The listed G series 
of audio codecs are recommendations from the Interna- 
tional Telecommunication Union (ITU). Other types of 
codecs may be supported by terminals in further em- 
bodiments. 

[0030] Generally, higher compression leads to a re- 
duced amount of data so that data transfer rate require- 
ments over a link may be reduced. However, because 
compression of data may cause loss of information, au- 



dio quality may be adversely affected. Thus, the two ob- 
jectives of higher quality audio and lower data transfer 
rate requirements may conflict. 

[0031] Conventionally, an origination terminal that de- 
5 sires to establish a voice communication with a destina- 
tion terminal sends a list of supported codecs to the des- 
tination terminal. In response, the destination terminal 
chooses an acceptable codec from the list. Such a proc- 
ess is provided by the H.323 protocol, which is a recom- 
io mendation for packet-based multimedia communica- 
tions systems from the ITU-T. Although such a process 
allows voice communications employing a commonly 
supported codec between the origination and destina- 
tion terminals, it does not take into account the capacity 
15 and usage of the link and other transmission resources 
between the terminals, in this case the data network 20, 
as well as other transmission or communications re- 
sources. 

[0032] Another resource element is the network pack- 

20 et size supported by the codec to communicate voice or 
other audio. As used here, network packet size refers 
to the size of the network packet used to carry audio 
data. In one embodiment, the packet includes an IP 
packet, which includes an IP header and IP payload. In 

25 further embodiments, other types of network packets 
may be employed, depending on the type of the data 
network 20. Inside the IP payload may be a TCP (Trans- 
mission Control Protocol) or UDP (User Datagram Pro- 
tocol) packet. A TCP or UDP packet includes a header 

30 and payload. For telephony communications, the pay- 
load of a UDP packet may include an RTP (Real-Time 
Transmission Protocol) packet. RTP is a protocol for the 
transport of real-time data, including audio and video. 
An RTP packet includes an RTP header and an RTP 

35 payload, which can carry one or more frames of audio 
data. TCP is described in RFC 793, entitled "Transmis- 
sion Control Protocol," dated September 1981. UDP is 
described in RFC 768, entitled "User Datagram Proto- 
col," dated August 1980. RTP is described in RFC 1B89, 

40 entitled "RTP: A Transport Protocol for Real-Time Ap- 
plications," dated January 1 996; and RFC 1 890, entitled 
"RTP Profile lor Audio and Video Conference with Min- 
imal Control," dated January 1996. 
[0033] A frame refers to the duration of a speech sam- 

45 pie. For example, a frame may be 10 milliseconds (ms), 
which indicates that a 10-ms sample of speech is con- 
tained in the frame. Other frames include 20 ms, 40 ms, 
and so forth, samples of speech. Each type of codec 
can support certain frame sizes. The number of frames 

50 that is placed into an RTP payload determines the size 
of the network packet (e.g., IP packet or other type of 
packet) used to carry the audio data. During a given call 
session, the number of frames to be carried in a network 
packet can be selected. The network packet size has 

55 implications on the burden placed on the data network 
in a given call session. Smaller network packets gener- 
ally are associated with higher overhead, since more au- 
dio data packets are communicated over the data net- 
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work 20 between terminals. Larger network packets are 
associated with reduced overhead, but come at the cost 
of longer delays since a longer speech sample is creat- 
ed between successive transmissions of audio over the 
data network 20. Thus, selection of network packet size 5 
(as determined by the selection of the number of frames 
to be carried in the packet) may also lead to a conflict 
between the objectives of higher quality audio and re- 
duced load on the data network 20 and other transmis- 
sion resources. 

[0034] In accordance with some embodiments, a call 
control mechanism implemented in the terminals, call 
server(s), policy server(s), and/or network monitor(s) of 
the telephony communications system 10 balances the 
need for high audio quality as well as the need to reduce 
burden on the data network 20 and other transmission 
resources. The call control mechanism selects a sup- 
ported codec, network packet size, and/or other re- 
source element that takes into account support for the 
resource element by all communicating terminals, the 
available capacity of the data network 20 and other 
transmission resources, and the objective to achieve the 
highest possible quality of service. Additional or different 
criteria may be used in other embodiments. 
[0035] An origination terminal communicates with the 
call server 12 over the data network 20 for call control 
signaling (to set up and terminate a call). After a con- 
nection is established between terminals over the data 
network, the terminals communicate media traffic (voice 
or other audio) and media traffic signaling with each oth- 
er through the data network 20. The call server 12 per- 
forms call setup processing, which includes translation 
of dialed digits (such as 10-digit telephone number) to 
an IP address of a destination terminal. The call server 
1 2 also keeps tracks of the status (e.g., busy, idle, down, 
and so forth) of the terminals that it is responsible for. In 
addition, the call server 12 keeps track of the usage of 
the transmission facility (the data network 20 and other 
transmission resources) by the telephony application. 
As used here, "telephony application" refers to one or 
more sessions of voice or other audio communications 
between or among the various terminals. 
[0036] Referring to the examples of Figs. 2-5, proc- 
esses for establishing a call between an origination ter- 
minal (e.g., the terminal 14, also referred to as terminal 
P 1 ) and a destination terminal (e.g. , the terminal 1 6, also 
referred to as terminal P2) are illustrated. In the embod- 
iments of Figs. 2-5, the call server 12 does not access 
the network monitor to select resource elements. An 
embodiment which does is described in connection with 
Figs. 7A-7B and 8. 

[0037] Fig. 2 illustrates the messages communicated 
between the various entities involved in call establish- 
ment, and Fig. 3 illustrates the tasks performed by the 
call server 12 in the call establishment process accord- 
ing to one embodiment. To start a call, the origination 
terminal 14, which has an IP address P1, sends a call 
request, such as a Call_Setup message, which is re- 



ceived (at 102) by the call server 12. The CalLSetup 
message includes a number identifying the destination 
terminal, a codec list including the codecs that are sup- 
ported by the terminal 14, a list of supported packet siz- 
es, and/or a list of other supported resource elements. 
Supported packet sizes are determined by the number 
of frames and the size of each frame (e.g., 10-ms frame 
20-ms frame, and so forth). Example codecs that are 
supported include G.711, G.728, G.729, G.729A, G. 
723.1, and G.722 codecs. The G.711 codec communi- 
cates uncompressed audio data and requires a 64-kbps 
data transfer rate, whereas the other codecs provide 
varying levels of data compression with lower data 
transfer rate requirements. For example, the G.728 co- 
dec requires a 16-kbps transfer rate, the G.729 codec 
requires an 8-kbps transfer rate, and the G. 723.1 codec 
requires a transfer rate of 6.3 kbps, 5.3 kbps, or less. 
[0038] In the call server 1 2, the list of available codecs 
and list of supported packet sizes in the Call_Setup 
message are received (at 1 04) and combined into a can- 
didate list. Alternatively, the different lists of resource el- 
ements may be maintained as separate candidate lists. 
[0039] Based on the CalLSetup message, the call 
server 1 2 translates (at 1 06) the number (e.g., the dialed 
number) of the called party into an IP address (e.g., ad- 
dress P2 of the destination terminal 16). Next, the call 
server 12 sends (at 107) a query message to the policy 
server 1 8. The query message includes the IP address- 
es of the origination and destination terminals (P1, P2) 
and a request for the usage policy for a telephony ap- 
plication between the pair of terminals at the present 
time. 

[0040] The policy server 1 8 responds to the query by 
sending a reply message back to the call server 12 to 
indicate the usage policy for the terminals P1 and P2 for 
the present call session. The usage policy information 
may be in the form of predetermined values represent- 
ing different levels of target usage for telephony com- 
munications. Alternatively, the usage policy information 
may be in the form of information identifying resource 
elements that- are supported or not supported at the 
present time. Based on the received usage policy infor- 
mation, the call server 1 2 updates (at 108) the candidate 
list by deleting unacceptable codecs. The policy server 
18 may set a low usage level for the telephony applica- 
tion because of high traffic carrying traditional data 
packets (e.g., e-mail traffic, web browsing traffic, file 
transfer traffic, and so forth). Thus, codecs that have 
high bandwidth requirements may be deleted (at 108) 
from the candidate list. Examples of such high band- 
width codecs include the G.711 codec. In addition, un- 
acceptable packet sizes are also deleted from the can- 
didate list (at 108), depending on the usage policy. If low 
usage level is indicated, then shorter packet sizes may 
be deleted from the list. Thus, the call server 12 selects 
one or more resource elements (e.g., codecs and pack- 
et sizes) that are supported based on the usage policy 
of the data network 20. 



15 



20 



25 



30 



35 



40 



45 



SO 



5 



JSDOCID: <EP 1079573A2_I_> 



9 



EP 1 079 573 A2 



10 



[0041] Optionally, the call server 12 can also perform 
an additional bandwidth restriction based on the usage 
of transmission resources. Each connection between a 
pair of terminals shares a pool of transmission resourc- 
es (links coupling the terminals that the call server 1 2 is 
responsible for, routers and gateways coupling the links, 
and other resources) with other applications. The call 
server 12 keeps track of the usage of the pool of trans- 
mission resources by tracking the number of voice calls 
and bandwidth usage. When the usage reaches a pre- 
determined threshold, the call server 1 2 may further limit 
the bandwidth usage. The call server 12 may use this 
limitation to further delete (at 110) unacceptable codecs, 
packet sizes, and other resource elements from the can- 
didate list so that a further reduced number of resource 
elements may be selected. 

[0042] The call server 12 then sends (at 112) a query 
message, e.g., a Query_Resource_Availability mes- 
sage, to the destination terminal P2 to identify the sup- 
ported codecs, packet sizes, and other resource ele- 
ments in the destination terminal P2. The results are re- 
turned in a Rep ly_Resource_Avai lability message, from 
which the call server 12 can determine the codecs, 
packet sizes, and other resource elements supported 
by the destination terminal P2. The candidate list ol co- 
decs, packet sizes, and other resource elements is up- 
dated based on the available codecs in the destination 
terminal P2, with unsupported codecs, packet sizes, 
and other resource elements deleted from the candidate 
list. 

[0043] Potentially, all codecs or packet sizes may 
have been deleted from the candidate list. If either the 
list of codecs or the list of packet sizes is empty (as de- 
termined at 114), then no supported codec or packet 
size exists to allow a call to proceed between the termi- 
nals P1 and P2, at which point the call server 12 sends 
(at 116) a message to terminate the call setup. The call 
server 12 also informs the origination terminal P1 of the 
setup failure. 

[0044] tf at least one codec and at least one packet 
size is available in the candidate list, then the call can 
proceed. If two or more codecs are present in the can- 
didate list, then the codecs are reordered (at 118) by 
applying a merit-based codec ranking algorithm to rank 
the codecs in the candidate list in the descending merit 
order (described further below). Packet sizes may also 
be ordered according to a merit ranking algorithm, as 
may other resource elements. The codec, packet size, 
and other resource element having the highest relative 
rank is selected. Alternatively, selection may be per- 
formed by the terminals : which may be adapted to select 
the highest ranking resource elements from a list. 
[0045] Next, the call server 12 sends a CalLSetup 
message to the destination terminal P2, with the 
Call_Setup message including an identifier of the calling 
party (either the calling terminal's telephone number or 
its IP address), the selected codec, packet size, and oth- 
er resource element. The call server 12 then proceeds 



(at 122) to the remaining tasks to be performed in the 
call setup, including sending a Select ed_Resource 
message identifying the selected codec, packet size, 
and other resource element back to the origination ter- 
s minal P1 . Alternatively, the codec, packet size, and oth- 
er resource element may be communicated as param- 
eters in a Setup_Connection message sent by the call 
server 1 2 to connect the call between terminals P1 and 
P2. A media path is then set up between the terminals 
P1 and P2. 

[0046] Although reference is made to selection of sev- 
eral resource elements, it is contemplated that further 
embodiments may select fewer than all the possible 
types of resource elements in the call management 
process. For example, call server 12 may perform se- 
lection of only codecs to manage bandwidth usage and 
quality of service on the data network 20. In addition, if 
multiple call servers are present in the data network 20, 
then communications may occur between call servers 
to enable selection of resource elements for establish- 
ing a call between terminals controlled by the call serv- 
ers. 

[0047] Referring further to Figs. 4 and 5, another em- 
bodiment of performing call establishment in which a co- 
dec, packet size, and/or other resource element are se- 
lected is illustrated. Fig. 4 illustrates messages ex- 
changed among the entities involved in the call estab- 
lishment, and Fig. 5 illustrates the tasks performed by 
the call server 12 in accordance with this embodiment. 
The tasks performed in the embodiment of Fig. 5 that 
are common to the tasks performed in the embodiment 
of Fig. 3 have the same reference numbers. As with the 
Figs. 2-3 embodiment, the origination terminal P1 sends 
a CalLSetup message to the call server 12 that includes 
a list of available codecs, a list of packet sizes, and a 
list of other resource elements, which are received in a 
candidate list (at 104) and updated (at 108) based on 
the usage policy in the data network 20 for the telephony 
application as determined from the policy server 18. 
This candidate list may further optionally be updated 
based on an internal table in the call server 12 on the 
usage of transmission resources (at 110). However, in- 
stead of querying the destination terminal P2 for its 
available codecs and supported packet sizes, the call 
server 12 in this alternative embodiment determines (at 
202) if the candidate list is empty at this point. If so, then 
a capable codec and packet size have not been found 
and the call setup is terminated (at 204). However, if the 
candidate list includes at least one codec and at least 
one packet size, the call server 1 2 reorders (at 206) the 
codecs and packet sizes (if more than one of each) in 
the candidate list according to a descending merit score. 
The candidate list is sent (at 208) by the caller server 
12 to the destination terminal P2 in a CalLSetup mes- 
sage to notify the destination terminal P2of an incoming 
call. At this point, the destination terminal P2 may com- 
pare the list of its supported codecs to the ones in the 
candidate list. The destination terminal P2 selects the 
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codec (and other resource elements) having highest rel- 
ative ranking from the candidate list that is also currently 
supported by the terminal P2 for the current call. If no 
capable codec or packet size exists, the destination ter- 
minal P2 informs the call server 12 of the rejection. The 
call server 12 determines (at 210) if a capable codec 
and packet size has been identified. If not (as deter- 
mined from receipt of the rejection message from the 
destination terminal P2), the call setup is terminated (at 
212). 

[0048] However, if a capable codec and packet size 
are identified, the destination terminal P2 informs the 
call server 12 of the selected codec through a 
CalLProgress message or some other message. If the 
call server 12 determines that a capable codec and 
packet size have been selected, then the call server 1 2 
transmits the selected codec and packet size (at 214) 
to the origination terminal P1 in a Setup_Connection 
message or some other message, such as a 
Select_Resource message. The call server 1 2 then pro- 
ceeds to the remaining tasks to perform for the call setup 
(at 216), after which a media path is established be- 
tween the origination terminal P1 and the termination 
terminal P2 for voice (or other audio) communications. 
[0049] Variations of tho processes described in con- 
nection with Figs. 2-5 may be performed periodically 
during a call session between two or more terminals. 
This allows modification of the selected resource ele- 
ment in response to increases or decreases in the avail- 
able bandwidth of the data network 20 and other trans- 
mission resources, including usage of resources in the 
terminals themselves. 

[0050] Referring to Fig. 6, components of an example 
terminal and call server are illustrated. In Fig. 6, the com- 
ponents of the terminal 14, 16, or 30 and call server 12 
are illustrated. As noted above, the terminal 14, 16, or 
30 can be one of many types of devices capable of com- 
municating voice over the data network 20. These ter- 
minals may include computer systems, telephones that 
are configured to communicate over a data network, a 
gateway system to the public switched telephone net- 
work (PSTN), and other communications devices. 
[0051] The layers of the terminal 14, 16, or 30 include 
a network interface controller 302 that is coupled to the 
data network 20. Above the network interface controller 
302 is a network device driver 304 and a network stack 
306, such as a TCP/IP or UDP/IP stack. Above the net- 
work stack 306 is an RTP layer 308 that performs vari- 
ous tasks associated with real time communications 
such as telephony communications. Incoming data from 
the data network 20 is received through the layers 302, 
304, 306 and 308 and routed to an audio codec 31 0, 
which has been selected from a number of available co- 
decs as discussed above. The incoming data is decod- 
ed by the codec 310 and routed to a digital-to-analog 
(D/A) converter 31 2 to produce the output at a speaker 
314. Outbound data to the network 20 originates at a 
microphone 316 or from an application routine 31 B. A 



user can speak into the microphone 316 to communi- 
cate voice data over the data network 20. Alternatively, 
the application routine 318 (or some other routine) may 
generate voice or other audio data to be transmitted to 
5 the data network 20. Examples of this may include an 
automated answering application, such as a voice mail 
application or a voice prompt application from which us- 
ers can select to access to various services. 
[0052] From the microphone, audio signals are 
passed through an analog-to-digital (A/D) converter 
320, which digitizes the audio signals and passes the 
digital audio data to the codec 310. The codec 310 en- 
codes the data and transmits the coded data down lay- 
ers 308, 306, 304, and 302 to the data network 20. The 
audio traffic is communicated through the data network 
20 to another terminal to which the terminal 14, 16, or 
30 has established a call connection. 
[0053] In addition to the audio traffic path, a control 
path exists between the terminal 14, 16, or 30 and the 
call server 12 lo set up, maintain, and terminate voice 
calls over the data network 20. In the terminal 14, 16, or 
30 one or more application routines 318 may generate 
control messages that are transmitted to the call server 
1 2 through the network stack 306, network device driver 
304, network interface controller 302, and the data net- 
work 20. Control signaling from the call server 1 2 is sim- 
ilarly received through the same layers from the data 
network 20 back to the one or more application routines 
318. 

[0054] In the call server 12, similar layers may exist. 
A network interface controller 330 in the call server 12 
is coupled to the data network 20. Above the network 
interface controller 330 is a network device driver 332 
and a network stack 334, such as a TCP/IP or UDP/IP 
stack. One or more call processing routines 336 in the 
call server 12 control the management of calls between 
terminals that are assigned to the call server 12. The 
call processing routines 336 perform the establishment 
of calls, maintenance of calls, and termination of calls. 
The call processing routines 336 may also periodically 
determine the available usage of the data network 20, 
which may cause it to update the codec and packet size 
used by the terminals in the voice communication ses- 
sion over the data network 20. For example, the call 
server 12 may maintain a usage table 351 to keep track 
of the number of active telephony calls and the usage 
(based on selected resource elements). 
[0055] In each terminal and call server, various soft- 
ware routines or modules may exist, such as the one or 
more application routines 318, network stack 306 : and 
device driver 304 in the terminal 14, 16, or 30 and the 
one or more call processing routines 336, network stack 
334, and device driver 332 in the call server 1 2. Instruc- 
tions of such software routines or modules, and others, 
may be stored in storage units 344 and 349 in the ter- 
minal and call server, respectively. The storage units 
344 and 349 may include machine-readable storage 
media including memory devices such as dynamic or 
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static random access memories, erasable and program- 
mable read-only memories (EPROMs), electrically 
erasable and programmable read-only memories (EEP- 
ROMs), and flash memories; magnetic disks such as 
fixed, floppy and removable disks; other magnetic me- 
dia including tape; and optical media such as compact 
discs (CDs) or digital video discs (DVDs). 
[0056] The instructions may be loaded and executed 
by control units 340 and 348 in the terminal and call serv- 
er, respectively, to perform programmed acts. The con- 
trol units 340 and 348 may include microprocessors, mi- 
crocontrollers, application-specific integrated circuits 
(ASICs), programmable gate arrays (PGAs), or other 
control devices. The terminal 14, 16, or 30 may also in- 
clude a digital signal processor 346 tor performing arith- 
metic intensive operations such as compression and de- 
compression operations performed by the audio codec 
310. 

[0057] The instructions of the software routines or 
modules may be loaded or transported into a system or 
device in one of many different ways. For example, code 
segments or instructions stored on floppy disks, CD or 
DVD media, the hard disk, or transported through a net- 
work interface card, modem, or other interface mecha- 
nism may be loaded into the system or device and ex- 
ecuted as corresponding software routines or modules, 
in the loading or transport process, data signals that are 
embodied as carrier waves (transmitted over telephone 
lines, network lines, wireless links, cables : and the like) 
may communicate the code segments or instructions to 
the system or device. 

[0058] The following discusses the merit-based co- 
dec ranking in accordance with one embodiment. A 
modified ranking system may be provided for packet 
size and/or other resource element selection. The call 
server 12 maintains a table of characteristics of each 
codec including the following attributes: voice quality 
(Q), bandwidth usage (B), andterminal DSP (e.g., digital 
signal processor 346 in Fig. 6) resource usage (R). The 
Q, B, and R attributes may contain numeric values 
(ranging between 0 and 1). The attribute B in one em- 
bodiment may represent the inverse of the actual band- 
width usage, that is, a higher B value indicates low band- 
width usage and a low B value indicates high bandwidth 
usage. A higher value of R indicates lower consumption 
of DSP resources. The attribute R similarly represents 
the inverse of the actual DSP usage. A merit factor M 
can be computed for each codec in the candidate list as 
a linear combination of the attributes Q, B, and R ac- 
cording to the following equation: 

M = W Q * Q + W B * B + W R * R, 

where W Q , W B , and W R are weights that are assigned 
to the attributes Q, B, and R, respectively. The values 
of the weights W Ql W B , and W R may be dynamic and 
can be based on usage of the pool of transmission re- 



sources used for the telephony application. Thus, in one 
example embodiment, the values of the weights W Q , 
W B , and W R may be assigned as following: 

W Q = (1 -t) * 0.8, W B = t, and W R = (1 -t) * 0.2, 

where t is the percentage usage of the pooled transmis- 
sion resources for the telephony application. The co- 
decs in the candidate list may be arranged in descend- 
ing order of the merit factor M in one embodiment, from 
which a codec can be selected for use in the call to be 
established. 

[0059] Thus, according to one embodiment, the merit 
factor M is higher for codecs having relatively high audio 
quality (Q), low expected bandwidth (e.g., data transfer 
rate) usage (B), and low expected DSP usage (R). Co- 
decs having relatively low audio quality, high expected 
bandwidth usage, and high DSP usage will have a lower 
M value. Thus, generally, the value of the merit factor M 
is increased with higher audio quality and decreased us- 
age of transmission resources (e.g., links in the data net- 
work 20 and DSP 346). 

[0060] As noted above, the telephony communication 
system 10 includes a network monitor 1 9 for monitoring 
various characteristics and conditions of one or more 
portions of the data network 20. Multiple network mon- 
itors may be present for monitoring different portions of 
the data network 20. The characteristics and conditions 
monitored include packet delay, jitter, and percentage 
of packet loss. 

[0061] The network monitor 1 9 may perform monitor- 
ing of a network link in a number of different ways. One 
technique is to use a network monitor having two differ- 
ent nodes on a network link. One node of the network 
monitor can send test packets targeted to the other node 
in the network monitor 19. From the transmission and 
receipt (or lack of receipt) of test packets, the nodes of 
the network monitor 19 can determine the delays in 
transmissions of packets as well as the percentage of 
packet loss. The network monitor 1 9 can periodically 
communicate test packets to monitor the link on a peri- 
odic basis. Such a technique may be referred to as a 
static monitoring technique. 

[0062] A dynamic technique to monitor a link is to ac- 
cess routers or gateways that communicate with the 
link. Routers and gateways maintain management infor- 
mation that keep track of delays being experienced with 
links that the routers and gateways are coupled to as 
well as amounts of packets that are being lost. Thus, 
each time a call server accesses a network monitor to 
request the current characteristics and conditions of a 
particular link, the network monitor can issue a query to 
a particular gateway or router to determine the current 
conditions. 

[0063] In further embodiments, the network monitor 
19 may also provide end-to-end delay and packet loss 
information based on the several classes of service that 
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may be supported, such as those in a quality-of-service 
(QOS) enabled network. For example, if the data net- 
work 20 employs differential services (Diffserv) to pro- 
vide QOS, different classes of packets may be defined 
based on assigned Diffserv code points (DSCPs). One 
class of packets may include packets delivering voice 
or other audio data. Other classes may be defined for 
other types of data that may be communicated through 
the data network 20. The different classes of packets 
may be routed through different queues through net- 
work nodes so that higher priority classes of packets are 
delivered more quickly. The network monitor 19 may 
track the delays and packet loss information by DSCP, 
with one DSCP assigned for the voice-over-IP class of 
service. 

[0064] Once the packet delay and loss information is 
determined by the call server 1 2, the call server 1 2 can 
access a database of models (referred to as E-models) 
for each call server to determine if a codec can satisfy 
a desired level of quality based on the prevailing network 
link conditions. E-models (represented in the form of 
charts) may also be maintained for the other resource 
elements. Two E-model charts 350 and 352 are illustrat- 
ed in Figs. 7A and 7B for the G.729A and G.723.1 co- 
decs; respectively. Each E-model includes a chart map- 
ping packet delays and percentage of packet loss to a 
desired quality level. In each E-model chart 350 or 352, 
an R value represents the desired quality of service. The 
call server 1 2 may maintain profiles and policies estab- 
lishing the desired R-values of calls between different 
combinations of callers. For example, for internal calls 
within an organization, a lower quality of service (and 
therefore lower R value) may be established, whereas 
external calls are set at higher R values. Other embod- 
iments may use different representations of the quality 
of audio service of codecs and other resource elements. 
[0065] In the chart 350 for the G.729A codec, the hor- 
izontal axis represents packet delay and the vertical axis 
represents the R value. The curves 360A-3601 repre- 
sent different percentages of packet losses. In one ex- 
ample, the curve 360A represents a 0% packet loss, the 
curve 360B represents a 0.5% packet loss, the curve 
360C represents a 1% packet loss, the curve 360D rep- 
resents a 1.57o packet loss, the curve 360E represents 
a 2% packet loss, the curve 360F represents a 3% pack- 
et loss, the curve 360G represents a 4% packet loss, 
the curve 360H represents an 8% packet loss, and the 
curve 3601 represents a 16% packet loss. Thus, as il- 
lustrated in Fig. 7A, the higher the delay and percentage 
packet loss, the lower the R value. In one embodiment, 
an R value of 90 generally indicates that users are very 
satisfied, an R value of 80 generally indicates that users 
are satisfied, an R value of 70 generally indicates that 
some users are dissatisfied, an R value ol 60 generally 
indicates that many users are dissatisfied, and an R val- 
ue of 50 and below generally indicate that nearly all us- 
ers are dissatisfied with the level of service. 
[0066] The chart 352 in Fig. 7B for the G.723. 1 codec 



is similar to the chart 350 in Fig. 7A, with the curves 
362A-362I representing corresponding percentages of 
packet loss to curves 360A-360I in Fig. 7A. Thus, given 
the current packet delay and percentage of packet loss, 
5 the charts of the E-models for the various codecs may 
be accessed to determine which codec can support the 
desired R value. In further embodiments, different mod- 
els may be used for codec or other resource element 
selection. 

io [0067] Thus, referring to Fig. 8, in accordance with an 
alternative embodiment that uses E-model charts, such 
as 350 and 352, the call server 12 receives (at 370) a 
call request from an origination terminal. The call re- 
quest may identify the resource elements, including co- 

15 decs, supported by the origination terminal. The call 
server can perform (at 371 ) selection of the codecs and 
other resource elements based on the usage policy and 
usage of transmission resources, including the data net- 
work 20, as described above in connection with Figs. 

20 2-5. This may reduce the number of codecs and other 
resource elements. 

[0068] Further, based on the profiles and policies as- 
sociated with the identified origination and destination 
terminals in the call request, the call server identifies (at 

2S 372) the target quality of service (R value). Next, the call 
server 1 2 can send (at 374) query messages to the net- 
work monitor 1 9 to determine the current characteristics 
and conditions of the network 20, including network de- 
lay and packet loss. Based on the identified delay and 

30 packet loss information, the call server 12 accesses (at 
376) the E-model charts of the supported codecs. From 
the E-model charts, the call server 1 2 identifies (at 378) 
the codecs and other resource elements that satisfy the 
target R value. Next, the codecs and other resources 

35 may be ranked (at 380) as described above based on 
various merit attributes to enable selection of one of the 
codecs and other resource elements to use during the 
call, as described above. 

[0069] Some embodiments of the invention may pro- 

40 vide one or more of the following advantages. A flexible 
codec (and other resource element) selection strategy 
is provided to enforce a policy based on the codec data 
rate between a pair of terminals where the codec (and 
other resource element) selection takes into account the 

45 capacity and resource limitation of the terminals as well 
as network traffic load and actual transmission resource 
usage in each terminal. Selection of resource elements 
may also be based on the prevailing characteristics and 
conditions of the network, such as delay and packet 

50 loss. Fine policy control over telephony traffic over a da- 
ta network is made available. Selection may be biased 
towards high voice quality when traffic is light; however, 
rf other network traffic high, then voice quality may be 
reduced to reduce the load on the data network. 

55 [0070] The codec and other resource element selec- 
tion technique and apparatus may be used with other 
applications. For example, for video conferencing com- 
munications sessions over a packet-based data net- 
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work, selection of video codecs may also be used to re- 
duce load on the data network. 

[0071] Another aspect of managing telephony com- 
munications over a data network is call admission con- 
trol. A call admission procedure determines whether to 
accept a call request from an origination terminal. If a 
data network, or any portion of the data network, has 
become saturated with traffic (both audio and traditional 
data packet traffic), then further call requests may be 
denied to ensure some predetermined quality of service. 
According to one embodiment of the invention, call ad- 
missions is based on usage of links between different 
groups of terminals (with the groups referred to as com- 
munities). Each community includes multiple terminals 
that are capable of communicating with each other with- 
out being subjected to call admissions control. This is 
made possible by grouping terminals that are coupled 
to high capacity links, such as LANs. As used here, a 
community refers to a group of terminals that are cou- 
pled by links having relatively high bandwidth. Such ter- 
minals may be located geographically close to each oth- 
er or they may be located over large distances. 
[0072] Within each community, voice calls between 
terminals are allowed to proceed when requested. In 
one embodiment, to provide some limitation on band- 
width usage of the communication link within each com- 
munity, resource element selection (such as the codec 
and packet size selection described above) may be 
used to limit the bandwidth of each call session when 
large numbers of call sessions are present in the com- 
munity. In other embodiments, resource selection may 
be skipped for intra-community calls. The call admission 
control in some embodiments of the invention is provid- 
ed for calls made between communities based on usage 
of the links among the communities. 
[0073] Referring to Fig. 9, one arrangement of a voice 
communication system 400 that includes communities 
is illustrated. The illustrated multiple links between ter- 
minals are logical links, not physical links. The logical 
links are part of the overall data network, with each link 
corresponding to a path through the data network be- 
tween any two terminals. In Fig. 9, each of the three 
communities 402, 404, and 406 includes its set of ter- 
minals. In the community 402, terminals 408 are cou- 
pled to a link 409 (e.g., a LAN, WAN, or other network). 
A call server 41 0 is also coupled to the link 409 to man- 
age calls between or among the terminals 408 and be- 
tween one or more of the terminals 408 and a terminal 
external to the community 402. The first community 402 
is coupled to the second community 404 over a link. In 
the second community 404, terminals 414 are coupled 
to an internal link 415. The second community 404 is 
coupled over another external link 430 to a third com- 
munity 406. An internal link 421 in the community 406 
is connected to terminals 420. In the illustrated embod- 
iment, the second and third communities 404 and 406 
share a call server 416, which manages calls within 
each of, or between, the communities 404 and 406 as 



well as between a terminal in one of the communities 
404 and 406 and another community, such as commu- 
nity 402. Each server maintains a list of its assigned 
communities and terminals in each of those communi- 
s ties. 

[0074] Generally, the links 430 and 432 (and other ex- 
ternal links connecting communities) have lower band- 
widths than the internal links in each of the communities. 
However, it is contemplated that exceptions to this exist 

io where an external link may have higher bandwidth than 
an internal link. For a given community I, the following 
parameters may be defined: L,, which represents the 
limit on a total available bandwidth between the com- 
munity and a device or system external to the commu- 

15 nity; M h which represents the threshold at which rese- 
lection of a codec, packet size, or other resource ele- 
ment is performed to reduce load on a link in a commu- 
nity; N,, which represents a threshold to restrict outgoing 
calls; and T h which represents the usage of the trans- 

20 mission resources in the community. 

[0075] Thus, according to one embodiment of a call 
admission control, outgoing new call requests from the 
community I may be denied if the value of T, exceeds 
the threshold N ( . If the traffic T, exceeds the threshold 

25 m,, then the call server for the community I can start to 
perform codec and other resource selection to reduce 
traffic. Thus, as described above in connection with 
Figs. 2-5, a call server may discard codecs and/or other 
resource elements based on transmission resources 

30 that the call server monitors, including the several 
thresholds L h M,, and N, of the community I. In one em- 
bodiment, the value of M, is about 60% to 80% of L,. The 
value of N, can be set at a value closer to or at L h 
[0076] Further, a pair-wise limit can be added for call 

35 admission control between communities. In this embod- 
iment, for a given community link between two commu- 
nities I and J, the following parameters may be defined: 
L,j, which represents the limit on a total bandwidth to be 
used by the community link IJ for the telephony applica- 

40 tion; M,j, which represents the threshold at which re- 
source element selection is performed; and T,j, which 
represents the usage of transmission resources of the 
community link IJ. A community link does not have an 
N parameter since a link has no direction and the con- 

45 cept of incoming or outgoing calls does not apply, 

[0077] For a terminal in community I to establish a 
new call with a terminal in community J, the following 
must be satisfied: 

so 

T | <N,andT |J <L |J . 

[0078] The first clause essentially states that the traf- 
fic between community I and all other communities must 
5S be less than the threshold limit N,. The value of T, is the 
sum of all traffic between community I and all other com- 
munities, that is 
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[0079] The second clause (T,j < L tJ ) specifies that the 
traffic on the link IJ between communities I and J must 
be less than the threshold L u . If either of the two clauses 
are not satisfied, then the call request from a terminal in 
community I is denied. A threshold My is also specified 
for the link IJ between communities I and J to specify a 
limit at which resource selection is performed. 
[0080] The limits L,, L| J} M,, and M, j may be static 
(that is, they remain fixed) or adaptive (that is, they may 
change with changing conditions of the data network). 
For example, as the data network traffic increases, the 
threshold values may decrease. The call server can col- 
lect statistics regarding the network (such as by access- 
ing a network monitor or other node such as a router or 
gateway) lo determine the conditions of the network. 
Based on the conditions, e.g., large delays or packet 
losses, the threshold values may be decreased to main- 
tain high quality of service. 

[0081] As illustrated in Fig. 9, the first community 402 
has the following paramoters: T-, , L-j , fv^ , ; the second 
community 404 has the following parameters: T 2 , L 2 , 
M 2 , and N 2 ; and the third community 406 has the follow- 
ing parameters: T 3 , L 3 , M 3 , and N 3 . The community link 
432 has the following parameters: T l2 , L 12 , M 12 ; and the 
community link 430 has the following parameters: T 23 , 
L 23 , and M 23 . 

[0082] Referring to Figs. 10A-10B, the call admis- 
sions control procedure is illustrated for a call between 
an origination terminal in one community (community I) 
and a destination terminal in a second community (com- 
munity J). In the example of Figs. 10A-10B, a first call 
server 500 services community I and a second call serv- 
er 501 services community J. The call server 500 re- 
ceives a Call_Setup message from a terminal in com- 
munity I that includes a list of supported audio codecs 
and a list of supported packet sizes. The call server 500 
then determines (at 502) whether the call is an intra- 
community or an inter-community call. If the call is an 
intra-community call then the call server 500 in commu- 
nity I performs intra-community call processing and ex- 
changes messages between the terminals involved in 
the call session (at 504). Codec and other resource el- 
ement selection may be performed as described above 
if the traffic T, exceeds the threshold value M,. 
[0083] If the call is an inter-community call, then the 
call server 500 determines (at 506) the name of the orig- 
ination community, in this case community I. The call 
server 500 then chocks the attributes L,, M,, and N, of 
the community I. At this point, the call server 500 checks 
the traffic T, (between community I and all other com- 
munities) against the limit N,. If T, exceeds N h then the 
call is denied by the call server 500. However, if the call 
request is allowed to proceed, then a candidate list of 



codecs and packet sizes is then created. Such a list of 
codecs and packet sizes may be further restricted based 
on the values of the thresholds L,, M h and N,. The band- 
width for community I is reserved to reserve capacity for 
the requested call. This allows the call server 500 to 
monitor the available bandwidth for further inter-com- 
munity call requests from terminals in the community I. 
[0084] A call request message is sent (at 508) from 
the call server 500 to the call server 501 that is assigned 
to community J. The message includes the name of the 
origination community I as well as the candidate list of 
codecs and packet sizes. In response to the message 
from the call server 500, the call server 501 determines 
the destination community name J, the community link 
IJ, and checks the limits Lj, Mj, and Nj, L u and M u (at 
510). Such a check includes checking if value of T u ex- 
ceeds L,j. Also, the value of Tj (total traffic of inter-com- 
munity calls between community J and all other commu- 
nities) is evaluated against Lj. If Tj exceeds Lj or T g 
exceeds L t j, then the call is denied and the call server 
501 informs the call server 500 of the call termination. 
The call server 501 may also check T|j against M,j, and 
Tj (total traffic from community J) against Mj, to deter- 
mine if resource selection is needed. 
[0085] From the limits, the call server 501 may further 
restrict the list of allowed codecs and packet sizes. 
Bandwidth is then reserved for the community J and link 
I J for the requested call. The call server 501 then sends 
a Call_Setup message (at 51 2) to the destination termi- 
nal in community J. The Call_Setup message includes 
the codec and packet size candidate list. In response to 
the CalLSetup message, the destination terminal sends 
back a CalLConnect message (at 514) that identifies a 
selected codec and a packet size. The call server 501 
and destination terminal may select a codec and packet 
size using techniques described in connection with Figs. 
2-5, which uses a ranking algorithm. Based on the re- 
turned CalLConnect message identifying the selected 
codec and packet size, the call server 501 corrects (at 
51 6) the expected bandwidth usage of community I and 
link !J. The call server 501 then sends back (at 518) a 
Connect/ Answer message to the call server 500 that in- 
cludes an identification of the termination community 
link (J) and the selected codec and packet size. Based 
on the identification of the selected codec and packet 
size, the expected bandwidth usage in the community I 
for the call session is corrected, and the expected band- 
width usage of the community link IJ is updated (at 520). 
[0086] At this point, a call has been connected be- 
tween the origination terminal and the destination termi- 
nal in communities I and J, respectively. If the origination 
terminal desires to terminate the phone call, then it 
sends a release message (at 522) to the call server 500. 
In response, the call server 501 updates (at 530) its 
bandwidth usage of community I and link IJ and sends 
a release message (at 524) to the call server 501 . In 
response to the release message, the call server 501 
updates (at 526) the bandwidth usage for community J 
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and link IJ to reflect termination of the call. The call serv- 
er 501 sends a release complete message (at 528) to 
the destination call server to terminate the call. 
[0087] In some cases, it is easy to determine whether 
or not a call is intra-community or inter-community. For s 
example, the translation component in a call server can 
be equipped with information indicating whether or not 
the call request is for an intra-community call. However, 
in some other cases, the origination terminal's call serv- 
er cannot accurately determine if a call request is for an to 
intra- or inter-community call. For example, although a 
call request may identify a destination terminal in anoth- 
er community, the destination terminal may have for- 
warded the call back to a terminal in the origination com- 
munity. In this case, the origination terminal's call server *5 
may assume that the call is an inter-community call and 
delete any codecs and other resource elements from the 
candidate list based on the origination terminal's com- 
munity threshold values. However, the call may still be 
determined to be an intra-community call by a second 20 
call server associated with the assumed destination ter- 
minal. The second call server may determine that the 
call has been forwarded back to the community of the 
origination terminal. Thus, in an embodiment in which 
intra-community calls are not subject to resource ele- 2s 
ment selection, the call request should not be denied 
even if the resulting candidate list is empty since the call 
may be forwarded back to the origination terminal's 
community for an intra-community call. However, if the 
call is indeed inter-community, and the candidate codec 30 
list is empty, then the call is denied by the second call 
server. 

[0088] A call management method and apparatus has 
been described to offer call admissions control and se- 
lection of resource elements to more effectively manage 35 
usage of a data network for telephony communications 
while providing a higher quality of service. 
[0089] While the invention has been disclosed with re- 
spect to a limited number of embodiments, those skilled 
in the art will appreciate numerous modifications and *o 
variations therefrom. It is intended that the appended 
claims cover all such modifications and variations as fall 
within the true spirit and scope of the invention. 



Claims 

1. A method of managing calls over a data network, 
comprising: 

so 

determining usage information of the data net- 
work; 

receiving a call request for establishing a call 
between at least two network terminals; and ss 

selecting one or more of a plurality of resource 
elements as candidates for use in the request- 



ed call in response to the call request based on 
usage information of the data network. 

2. The method of claim 1, wherein the selecting in- 
cludes selecting one or more resource elements 
based on usage policy set by a policy server. 

3. The method of claim 1, wherein the selecting in- 
cludes selecting one or more resource elements 
based on actual usage of the data network. 

4. The method of claim 1 , wherein the selecting in- 
cludes selecting one or more codecs as candidates 
for use in each network terminal. 

5. The method of claim 1 , wherein the selecting in- 
cludes selecting one or more sizes of a packet as 
candidates for carrying audio data in the requested 
call. 

6. The method of claim 1, further selecting one or more 
of the plurality of resource elements based on sup- 
port for the one or more resource elements in each 
of the at least two network terminals. 

7. The method of claim 1 , further comprising ranking 
the resource elements according to merit based on 
quality of the requested call and expected band- 
width usage of the data network. 

8. The method of claim 7, wherein the ranking of the 
resource elements is further based on expected us- 
age of a digital signal processing element of each 
terminal. 

9. The method of claim 1 , further comprising determin- 
ing a condition of the data network, wherein the se- 
lecting is further based on the determined condition. 

10. The method of claim 9, wherein the determining in- 
cludes determining a delay in the transmission of 
packets in the data network. 

11. The method of claim 9, wherein the determining in- 
cludes determining a percentage of packet loss in 
the data network. 

12. The method of claim 9, further comprising determin- 
ing an expected quality of service based on the de- 
termined condition of the data network. 

13. The method of claim 1, further comprising perform- 
ing call admissions control to accept or deny the call 
request. 

14. The method of claim 1 3, wherein performing call ad- 
missions control is based on usage of a link in the 
data network between groups of terminals. 
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15. The method of claim 13, wherein the at least two 
terminals are defined in at least two communities 
coupled by a link, and wherein performing call ad- 
missions control includes performing call admis- 
sions control based on a threshold set for the link 
between the communities. 

16. The method of claim 15, further comprising bypass- 
ing the call admissions control within each commu- 
nity. 

17. The method of claim 16, wherein selecting one or 
more resource elements is performed in each com- 
munity. 

18. A server for managing calls in a system having a 
network, comprising: 

an interlace to the network to receive a call re- 
quest to establish a call between Iwo endpoinls 
on the network; and 

a control unit adapted to process the call re- 
quest and to control selection of one of a plu- 
rality of resource elements to bo employed by 
the endpoints in the call. 

19. The server of claim 18, wherein the control unit is 
adapted to retrieve information regarding usage of 
the network, the control unit controlling selection of 
the one resource element based on the usage. 

20. The server of claim 18, wherein the resource ele- 
ments include codecs to be employed by the end- 
points in the call. 

21. The server of claim 18, wherein the resource ele- 
ments include sizes of messages to be used for car- 
rying audio data in the call. 

22. The server of claim 21, wherein the sizes of mes- 
sages are determined by a selected number of 
frames carrying audio data in each message. 

23. The server of claim 1 8, wherein the calls include te- 
lephony calls. 

24. The server of claim 18, wherein the control unit is 
adapted to rank the resource elements by one or 
more predetermined criteria. 

25. The server of claim 24, wherein the control unit is 
adapted to select the resource element having a 
highest relative rank. 

26. The server of claim 25, wherein the control unit is 
adapted to determine resource elements supported 
by the endpoints. 



27. The server of claim 24, wherein the control unit is 
adapted to present the ranked resource elements 
to at least one of the endpoints for the at least one 
endpoint to select a resource element. 

5 

28. A computer program product capable ol running in 
a system so that the system so programmed carries 
out a method including: 

10 receiving a call request containing information 

identifying an origination endpoint, a destina- 
tion endpoint, and one or more resource ele- 
ments supported by the origination endpoint; 

*5 selecting one or more of the one or more re- 

source elements based on perceived audio 
quality and usage of a data network; and 

presenting the selected one or more resource 
20 elements as available for use in a call between 

endpoints. 

29. A method of managing calls in a telephony system, 
comprising: 

25 

defining a plurality of communities each includ- 
ing one or more communication endpoints; 

assigning one or more usage threshold values 
30 to a link between communities; and 

processing a call request based on the one or 
more usage threshold values, 

35 wherein the processing includes determining 

whether to admit the call request over the link. 

30. The method of claim 29, wherein the processing fur- 
ther includes selecting one or more resource ele- 

40 ments to be used during a call between endpoints 
over the link. 

31. The method of claim 29, wherein the assigning in- 
cludes assigning a threshold value indicating the 

45 available bandwidth on the link between the com- 
munities. 

32. The method of claim 29, wherein the processing fur- 
ther includes selecting one or more resource ele- 

50 ments to be used during a call between endpoints 
over the link, and wherein the assigning includes 
assigning a usage threshold value over which the 
selecting is to be performed. 

55 33. The method of claim 29, wherein the assigning in- 
cludes assigning a usage threshold value over 
which further outgoing calls from a community is 
prohibited. 
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34. A call establishment method, comprising: 

determining a candidate list of coding resource 
members associated with a call request; 

5 

checking a usage policy for the call request; 

removing from the candidate list a first set of 
coding resource members whose bandwidth 
requirements exceed the usage policy; 10 

ranking a second set a coding resource mem- 
bers of the candidate list according to merit, the 
second set being distinct from the first set; 

is 

selecting from the second set of coding re- 
source member having a highest relative merit; 
and 

establishing a call specified by the call request 20 
using the selected coding resource member. 

35. The call establishment method of claim 34, wherein 
the determining includes: 

2S 

receiving at least one supported coding re- 
source of an endpoint specified with the call re- 
quest; and 

assembling the candidate list from the at least 30 
one received supported coding resource. 

36. The call establishment method of claim 35, wherein 
the call request specifies an originating endpoint 
and at least one destination endpoint; and 

wherein the receiving comprises receiving at 
least one supported coding resource member for 
each of the originating and at least one destination 
endpoints. 

37. The call establishment of claim 34, wherein the 
ranking comprises ranking the second set of coding 
resource members according to at least one of per- 
ceived voice quality, bandwidth usage, and end- 
point digital signal processing resource usage. 

38. The call establishment method of claim 34, wherein 
the call establishing fails to establish the call when 
the second set is empty. 

so 

39. A call server, comprising: 

means for determining usage information of the 
data network; 

ss 

means for receiving a call request for establish- 
ing a call between at least two network termi- 
nals; and 
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means for selecting one or more of a plurality 
of resource elements as candidates for use in 
the requested call in response to the call re- 
quest based on usage information of the data 
network. 
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(54) Managing calls over a data network 

(57) A method and system of managing calls over a 
data network (20) includes determining an available 
bandwidth of the data network (20). After a call request 
is received for establishing a call between at least two 
network terminals (14,16, 30), one or more of a plurality 
of resource elements are selected in response to the 
call request based on the bandwidth of the data network 
(20). The resource elements, which can include codecs 
(coders/decoders), packet sizes (for carrying audio da- 
ta), and others, are used in the requested call between 



the at least two network terminals (14, 16, 30). Further, 
a plurality of communities (402, 404, 406) may be de- 
fined each including one or more terminals. One or more 
usage threshold values may be assigned to a link or 
links (430, 432) between communities (402, 404, 406), 
and a call request is processed based on the one or 
more usage threshold values. The processing includes 
at least one of determining whether to admit the call re- 
quest and selecting resource elements to be used dur- 
ing a call between terminals over the link (430, 432). 
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